---
title: Release policy
---

import AlphaCallout from '/snippets/alpha-lc-callout.mdx';

<AlphaCallout />

This page explains the LangChain and LangGraph release policies. Click on the tabs below to view the release policies for each:

<Tabs>
    <Tab title="LangChain">

    :::python
    The LangChain ecosystem is composed of different component packages (e.g., `langchain-core`, `langchain`, `langchain-community`, partner packages, etc.)
    :::
    :::js
    The LangChain ecosystem is composed of different component packages (e.g., `@langchain/core`, `langchain`, `@langchain/community`, partner packages, etc.)
    :::

    ## Release cadence

    :::python
    We expect to space out **minor** releases (e.g., from 0.2.x to 0.3.0) of `langchain` and `langchain-core` by at least 2-3 months, as such releases may contain breaking changes.
    :::
    :::js
    We expect to space out **minor** releases (e.g., from 0.2.x to 0.3.0) of `langchain` and `@langchain/core` by at least 2-3 months, as such releases may contain breaking changes.
    :::

    Patch versions are released frequently, up to a few times per week, as they contain bug fixes and new features.

    ## API stability

    :::python
    The development of LLM applications is a rapidly evolving field, and we are constantly learning from our users and the community. As such, we expect that the APIs in `langchain` and `langchain-core` will continue to evolve to better serve the needs of our users.
    :::
    :::js
    The development of LLM applications is a rapidly evolving field, and we are constantly learning from our users and the community. As such, we expect that the APIs in `langchain` and `@langchain/core` will continue to evolve to better serve the needs of our users.
    :::

    - Breaking changes to the public API will result in a minor version bump (the second digit)
    - Any bug fixes or new features will result in a patch version bump (the third digit)

    We will generally try to avoid making unnecessary changes, and will provide a deprecation policy for features that are being removed.

    ### Stability of other packages

    The stability of other packages in the LangChain ecosystem may vary:

    :::python
    - `langchain-community` is a community maintained package that contains 3rd party integrations. While we do our best to review and test changes in `langchain-community`, `langchain-community` is expected to experience more breaking changes than `langchain` and `langchain-core` as it contains many community contributions.
    :::
    :::js
    - `@langchain/community` is a community maintained package that contains 3rd party integrations. While we do our best to review and test changes in `@langchain/community`, `@langchain/community` is expected to experience more breaking changes than `langchain` and `@langchain/core` as it contains many community contributions.
    :::
    - Partner packages may follow different stability and versioning policies, and users should refer to the documentation of those packages for more information; however, in general these packages are expected to be stable.

    ## Deprecation policy

    We will generally avoid deprecating features until a better alternative is available.

    :::python
    When a feature is deprecated, it will continue to work in the current and next minor version of `langchain` and `langchain-core`. After that, the feature will be removed.
    :::
    :::js
    When a feature is deprecated, it will continue to work in the current and next minor version of `langchain` and `@langchain/core`. After that, the feature will be removed.
    :::

    Since we're expecting to space out minor releases by at least 2-3 months, this means that a feature can be removed within 2-6 months of being deprecated.

    In some situations, we may allow the feature to remain in the code base for longer periods of time, if it's not causing issues in the packages, to reduce the burden on users.

    </Tab>
    <Tab title="LangGraph">
    LangGraph follows a structured release policy to ensure stability and predictability for users building production applications.

    ## Release cadence

    We expect to space out **major** releases by at least 6-12 months to provide stability for production applications.

    **Minor** releases are typically released every 1-2 months with new features and improvements.

    **Patch** releases are released as needed, often weekly, to address bugs and security issues.

    ## API stability

    ### Stable APIs

    All APIs without special prefixes are considered stable and ready for production use. We maintain backward compatibility for stable features within a major version.

    ### Beta features

    Features marked as `beta` in the documentation are:

    - Feature-complete and tested
    - Safe for production use with the understanding they may change
    - Subject to minor API adjustments based on user feedback

    ### Experimental features

    Features marked as `experimental` or `alpha`:

    - Are under active development
    - May change significantly or be removed
    - Should be used with caution in production

    ### Internal APIs

    APIs prefixed with underscore (`_`) or explicitly marked as internal:

    - Are not part of the public API
    - May change without notice
    - Should not be used directly

    ## Deprecation policy

    When deprecating features:

    1. **Deprecation Notice**: Features are marked as deprecated with clear migration guidance
    2. **Grace Period**: Deprecated features remain functional for at least one minor version
    3. **Removal**: Features are removed only in major version releases
    4. **Migration Support**: We provide migration guides and, when possible, automated tools

    ## Platform compatibility

    ### Python support

    - We support Python versions that are actively maintained by the Python Software Foundation
    - Python version requirements may change only in major releases
    - Currently requires Python 3.10 or later

    ### JavaScript/TypeScript support

    - We support Node.js LTS versions
    - TypeScript definitions are provided for all public APIs
    - Browser compatibility is documented for client-side components

    ## Breaking changes

    Breaking changes are only introduced in major versions and include:
    - Removal of deprecated APIs
    - Changes to required parameters
    - Changes to default behavior that affect existing applications
    - Minimum Python/Node.js version updates

    ## Migration support

    For major version upgrades, we provide:
    - Comprehensive migration guides
    - Automated migration scripts when feasible
    - Extended support period for the previous major version
    - Clear documentation of all breaking changes

    ## Long-term support (LTS)

    Selected versions may be designated as LTS releases:
    - Receive security updates and critical bug fixes for extended periods
    - Ideal for enterprise deployments requiring maximum stability
    - LTS status is announced at release time

    ## See also

    - [Versioning](/oss/versioning) - Version numbering and support details
    - [Releases](/oss/releases) - Version-specific release notes and migration guides
    </Tab>
</Tabs>
